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REMARKS/ARGUMENTS 

This Amendment is in response to the Office Action mailed August 3, 2009. 
Claims 1, 2, 4, 5, and 7-22 were pending in the present application. This Amendment amends 
claims 1,2, 10, 11, 19, and 22, leaving pending in the application claims 1, 2, 4, 5, and 7-22. 
Applicant submits that no new matter has been introduced by virtue of these amendments. 
Reconsideration of the rejected claims is respectfully requested. 

35 U.S.C. $ 112 Rejections of Claims 1, 2, 4, 5, and 7-22 

35 U.S.C. $ 1 12. first paragraph 

Claims 1, 2, 4, 5 and 7-22 are rejected under 35 U.S.C. §1 12, first paragraph, as 
failing to comply with the written description requirement. In particular, the Office Action 
asserts: 

The claim(s) contain subject matter which was not described in the specification 
in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the 
time the specification was filed, had possession of the claimed invention. Independent claims 1, 2, 
10, 1 1, 19 and 22 contain the phrases 'are not considered activities of a larger program' or 'are not 
stored as...' 

These claims do not. . . satisfy the written description requirement under 35 
U.S.C. §112, first paragraph as the aforementioned limitations are not described in the disclosure. 
(Office Action: pgs. 6-7). 
Applicant respectfully disagrees, and submits that support for the claimed feature 
"wherein the first and second programs are not stored as activities of another program by the 
computer system. . ." can be found in various portions of the Specification as filed. For example, 
paragraphs 1 1 and 12 of the Specification recite, in part: 

. . . Traditional Project Management only handled dependencies inside the 
project plan . Thus, critical developments outside the program could adversely affect profitability 
without warning. 

What is needed, therefore, is a scheduling system capable of creating, 
displaying, and managing cross-program dependencies . . . 
(Emphasis added). 
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Paragraph 14 of the Specification recites, in part: 

The present invention exists as a stand-alone software application and can also 
be a component of a broader set of software modules that comprise an overall program 
management suite. The present invention is directed to a scheduling system that establishes cross- 
program boundaries for phase, task, deliverable, and gate activities. 
(Emphasis added). 
And paragraph 35 of the Specification recites, in part: 

. . .Program manager A and Program manager B create separate programs with 

several tasks... 

(Emphasis added). 

As quoted above, the Specification clearly describes the concept of establishing, 
via a software application, interdepcndcncics between "separate programs," where the separate 
programs are not "inside a [single] project plan." In prior art program management software, 
interdependencies could only be defined between tasks or sub-programs within a given program. 
Thus, interdependencies in prior art software could not extend beyond "traditional program 
boundaries." Embodiments of the present invention overcome this limitation by allowing 
interdependencies to be established across programs that are not explicitly stored as activities or 
sub -activities of another program (e.g., a parent program). 

Applicant notes that "[t]he subject matter of the claim need not be described 
literally (i.e., using the same terms or in haec verba) in order for the disclosure to satisfy the 
description requirement." (MPEP Section 2163.02; emphasis added). Rather, "the fundamental 
factual inquiry is whether the specification conveys with reasonable clarity to those skilled in the 
art that, as of the filing date sought, applicant was in possession of the invention as now 
claimed." (MPEP Section 2163.02; emphasis added). As explained above, the Specification 
does convey, with reasonable clarity to one of ordinary skill in the art, that Applicant was in 
possession of the invention as recited in the claims. Accordingly, Applicant respectfully requests 
that the Section 1 12, first paragraph rejection of claims 1, 2, 4, 5, and 7-22 be withdrawn. 
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35 U.S.C. §112, second paragraph 

Claims 1, 2, 4, 5, and 7-22 are rejected under 35 U.S.C. §1 12, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. In particular, the Office Action asserts: 

First, the term 'considered' suggests some extra solution activity or some form 
of human intervention which entails additional steps as to how and when a decision or assessment 
is rendered as when a program is not considered part of a larger program. Secondly, the term 
'larger program' incorporates a relative term which renders the claim indefinite. 
(Office Action: pg. 8). 

Although Applicant disagrees with the rejection, solely in order to expedite 
prosecution Applicant has amended the claims to remove the terms "considered" and "larger 
program." Accordingly, Applicant respectfully requests that the Section 1 12, second paragraph 
rejection of claims 1, 2, 4, 5, and 7-22 be withdrawn. 

35 U.S.C. § 103 Rejection of Claims 1. 2. 4. 5. 9-14. 16. 18. 19. 20. and 22 

Claims 1, 2, 4, 5, 9-14, 16, 18, 19, 20, and 22 are rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over Robson (U.S. Patent No. 7,330,822, hereinafter "Robson") in 
view of Pollalis (U.S. Patent No. 5,016,170, hereinafter "Pollalis") and further in view of 
Rosnow et al. (U.S. Patent No. 7,05 1,036, hereinafter "Rosnow"). Applicant respectfully 
traverses. 

As discussed in the Specification, prior art program management applications 
generally do not support the creation of interdependency relationships across program 
boundaries (where the term "program boundary" is construed from the perspective of the 
software application). Rather, in such prior art applications, interdependencies can only be 
defined between tasks or sub-programs within a given program or project plan. (See 
Specification: paras. 11-13). For example, if programs A and B are created as separate programs 
in a prior art application, there is no way to establish an interdependency between A and B. This 
issue can be "worked around," to an extent, by redefining programs A and B as tasks or activities 
under a common parent program C (since prior art applications support interdependencies 
between activities within a given program). 
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In contrast to the prior art, certain embodiments of the present invention enable a 
computer system to establish and store an interdependency between two programs, even though 
the two programs may not be stored or defined as activities of another program (e.g., a parent 
program) by the system. For instance, in the example above, certain embodiments of the present 
invention would allow an interdependency to be created directly between programs A and B, 
without having to first move A and B under a common program C within the system. 

In accordance with the above, Applicant's independent claim 1 (as amended) 
recites, in part "receiving, at [a] computer system, an interdependency between a first activity in 
a first program and a second activity in a second program, wherein the first and second programs 
are not stored as activities of another program by the computer system." Applicants submit that 
at least this feature of claim 1 is not taught or suggested by Robson, Pollalis, or Rosnow, 
considered individually or in combination. 

In the Office Action, the Examiner apparently asserts that the "receiving. . . an 
interdependency. . ." feature of claim 1 is shown by Robson and Rosnow. (See Office Action: 
pgs. 3-6). In support of this argument, the Examiner cites column 9, lines 25-27 and column 5, 
line 20 of Robson, and column 15, line 40 and column 27, line 10 of Rosnow. (Office Action: 
pgs. 3, 6, and 1 1). Each of these cited sections will be addressed in turn below. As will be seen, 
these sections (either individually or in combination) fail to teach or suggest "receiving, at [a] 
computer system, an interdependency between a first activity in a first program and a second 
activity in a second program, wherein the first and second programs are not stored as activities of 
another program by the computer system." as recited in claim 1 . 

Robson 

Column 9, lines 25-27 of Robson (and its surrounding context) state: 

According to the present invention, the database 1 1 0, may store the tasks, Issues, 
Change Requests and Change Orders for a single project or for multiple projects. The user may 
retrieve a specific project by entering the necessary information in a project search screen, a 
simplified example of which is shown at 122 of FIG. 1. Thereafter, the database 110 may be 
searched and user selectable views of the desired project may be displayed on the user's browser, 
as shown at 123. 
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This section of Robson merely indicates that a database may store information 
pertaining to multiple projects, and that information pertaining to a specific project (among the 
multiple projects stored in the database) may then be queried from the database and viewed by a 
user. This section does not make any reference to receiving or maintaining interdependencies 
between multiple projects or programs as recited in Applicant's claim 1. 

It appears the Examiner is construing the phrase "tasks, Issues, Change Requests 
and Change Orders for a single project or for multiple projects" as somehow indicating that a 
single task/issue/change request/change order can be a part of multiple projects simultaneously. 
However, as best understood, there is no support for this construction in Robson, as the other 
sections of Robson always refer to tasks/issues/change requests/change orders within the context 
of a particular project. Given the Robson reference as a whole, one of ordinary skill in the art 
would construe the phrase "tasks, Issues, Change Requests and Change Orders for a single 
project or for multiple projects" as simply indicating that the database of Robson can store a set 
of tasks (and other information) for a single project, or multiple sets of different tasks for 
multiple projects. Accordingly, this section of Robson fails to teach anything about 
interdependencies between activities of two different programs, where the two programs are not 
stored as activities of another program by the computer system. 

The section of Robson surrounding column 5, line 20 states: 

It is understood that hierarchical tree structure 200 is but a partial illustration of 
an example of a large project. In practice, projects may be considerably more complex than 
suggested by FIG. 2 and the present invention is drawn to managing such complex projects. . . 

This section merely indicates that a project can be "complex" in that it can include 
a deeply nested hierarchy of tasks or other activities. Robson goes on to state that 
interdependencies can be created between tasks in a given project. (See Robson: col. 5, lines 24- 
27). 

The Examiner apparently construes this section of Robson as teaching that, since 
a complex project can include a deeply nested hierarchy of tasks or activities, one or more 
subtrees in the hierarchy of the project can be considered its own "sub-project." Further, since 
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interdependencies can be created between tasks in a project, interdependencies can also be 
created between "sub-projects." 

Even assuming arguendo that this construction is correct, the section of Robson 
starting at column 5, line 20 still fails to teach or suggest created interdependencies between 
programs that are not part of another program by the computer system . For example, while tasks 
Tl and T2 in a complex project P may be large enough in scale to be considered by a user as 
individual sub-projects or projects, Tl and T2 would still be defined in the system of Robson as 
being within the context of complex project P. In other words, Tl and T2 would both be defined 
and stored as a child object of P. Nowhere does this section (or any other section) of Robson 
indicate that an interdependency can be created between two separate projects , where the 
projects are not stored as part of a common parent project in the computer system . Accordingly, 
this section of Robson also fails to teach or suggest "receiving, at [a] computer system, an 
interdependency between a first activity in a first program and a second activity in a second 
program, wherein the first and second programs are not stored as activities of another program 
by the computer system." as recited in claim 1 . 

Rosnow 

The deficiencies of Robson are not cured by Rosnow. 

The section of Rosnow starting at column 15, line 40 states: 

The project planning system includes a knowledge repository as one or more 
databases in which project information is accumulated as projects are completed, dropped from 
consideration, or put on hold or halted during development. Thus, institutional knowledge and 
experience developed during previous or currently ongoing separate projects to develop new ideas 
is electronically captured in a comprehensive, organized manner in a searchable computer 
database within the inventive planning system. This feature permits a system user, and an 
assigned evaluator, such as a project leader, to investigate and identify any archived previous or 
ongoing related projects within the enterprise that might be related to the proposed new idea, and 
review the results of any identified related projects. . . 

And the section of Rosnow starting at column 27, line 10 states: 

By downloading an existing or former project(s) of interest, data and results 
electronically archived from the earlier projects can be reviewed and compared to content of the 
newly proposed concept. The search results help project leaders prevent duplicity of work 



Page 13 of 16 



Appl. No. 10/694,502 PATENT 
Amdt. dated October 28, 2009 
Examining Group 3624 

performed. Additionally, project leaders may find related projects with which they can share and 
collaborate with. . . 

As best understood, these sections merely describe the concept of allowing a 
project leader to search a database comprising information about a plurality of projects to 
identify existing projects that may be similar to a proposed project concept that the project leader 
is considering implementing. Based on the search, the project leader may for example, decide 
not to pursue the proposed concept, since an existing project already addresses the goal that the 
proposed concept seeks to achieve. Thus, "duplicity of work" is avoided since the project leader 
can avoid initiating a new project that is too similar to an existing project. 

Applicant submits that the notion of performing a manual search and review of 
existing projects fails to teach anything about receiving, at a computer system, an 
interdependency between separate programs, where the programs are not stored as activities of 
another program by a computer system. For example, nowhere do the cited sections indicate (or 
even suggest) that, once a project leader has found one or more existing projects, the project 
leader can submit to the computer system an interdependency between the projects, let alone an 
interdependency that causes an effect of a modification of an activity in a first project to be 
displayed on a schedule for a second activity in a second project as recited in claim 1. 
Accordingly, Rosnow also fails to teach or suggest "receiving, at [a] computer system, an 
interdependency between a first activity in a first program and a second activity in a second 
program, wherein the first and second programs are not stored as activities of another program 
by the computer system" as recited in claim 1 . 

For at least the foregoing reasons, Applicant submits that independent claim 1 is 
not rendered obvious by the cited art, and respectfully requests that the Section 103 rejection of 
claim 1 be withdrawn. 

Independent claims 2, 10, 11, 19, and 22 recite features that are substantially 
similar to independent claim 1 , and are thus allowable for at least a similar rationale as discussed 
for claim 1, and others. 
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Claims 4, 5, 9, 12-14, 16, 18, and 20 depend from independent claims 1,11, and 
19 respectively, and are thus allowable for at least a similar rationale as discussed for claims 1, 
11, and 19, and others. 

35 U.S.C. $ 103 Rejections of Claims 7, 8, 15, 17, and 21 

Claims 7, 8, 15, and 17 are rejected under 35 U.S.C. §103(a) as being 
unpatentable over Robson/Pollalis as applied to claims 3 and 1 1 and further in view of 
Applicant's own prior art. Claim 21 is rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Robson/Pollalis/Rosnow as applied to claim 19, and further in view of Abrams (U.S. Patent 
No. 7,305,392, hereinafter "Abrams"). Applicant respectfully traverses. 

Claims 7, 8, 15, 17, and 21 depend from independent claims 1,11, and 19 
respectively, which are not rendered obvious by Robson, Pollalis, and/or Rosnow as discussed 
above. Accordingly, claims 7, 8, 15, 17, and 21 are allowable for at least a similar rationale as 
discussed for claims 1,11, and 19, and others. 

Amendments to the Claims 

Unless otherwise specified, amendments to the claims are made for purposes of 
clarity, and are not intended to alter the scope of the claims or limit any equivalents thereof. The 
amendments are supported by the Specification as filed and do not add new matter. 

CONCLUSION 

In view of the foregoing, Applicant believes all claims now pending in this 
Application are in condition for allowance and an action to that end is respectfully requested. 



Page 15 of 16 



Appl.No. 10/694,502 
Amdt. dated October 28, 2009 
Examining Group 3624 



PATENT 



If the Examiner believes a telephone conference would expedite prosecution of 
this application, please telephone the undersigned at 650-326-2400. 



Respectfully submitted, 



/Andrew J. Lee/ 



Andrew J. Lee 
Reg. No. 60,371 

TOWNSEND and TOWNSEND and CREW LLP 

Two Embarcadero Center, Eighth Floor 

San Francisco, California 941 1 1-3834 

Tel: 650-326-2400 

Fax: 415-576-0300 
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